Networks such as the public Internet and private cellular networks carry data that is encapsulated by packets that are switched through the networks. As user applications become more sophisticated, the amount of data increases, such as to carry video rather than just voice. Networks tend to get swamped by such increases in traffic. Intermediate switches or routers may be overwhelmed by the number of packets received and may be forced to drop some of the packets.
Various traffic control techniques have been implemented. Rather than just drop packets randomly, traffic classes can be established. Packets for a lower-priority traffic class are dropped, while packets with higher-priority traffic classes are passed through a congested router. Thus the limited bandwidth of a congested router can be reserved for higher-priority traffic. The Quality-of-Service (QoS) for higher-priority packets can be improved.
Quality of Service (QoS) ensures that traffic receives the correct attention in a network. Inherently, the Internet fairly shares network resources on a packet-by-packet basis. However, different types of traffic may need different levels of service. Unfortunately the type of traffic is not visible on a packet by packet basis. Quality of Service encompasses a variety of traffic characteristics and control methods. Priority, maximum bandwidth, minimum bandwidth, latency, jitter, and error rates are parameters for QoS.
FIG. 1 shows a prior-art router that drops packets based on QoS rules. Router 10 is an intermediate node in a network such as the Internet and receives Internet Protocol (IP) packets 12, and routes these IP packets to other routers or devices along paths toward the packets' destinations.
Sometimes router 10 receives more incoming IP packets 12 than it can process. Router 10 may have an input buffer or queue that can store a limited amount of data. When too many IP packets 12 are received in a short period of time, this input buffer can fill up, and any additional IP packets are lost since there is no more room in the input buffer. Even when the input buffer does not overflow, packets entering the input buffer may be significantly delayed.
To prevent this input-buffer overflow, router 10 implements a traffic policy to guarantee a Quality-of-Service (QoS) for some higher-priority packets. QoS rules 14 are received from a centralized QoS traffic controller that monitors network traffic and issues updated to QoS rules 14 as network conditions change. For example, when there is no congestion on the network, QoS rules 14 may instruct router 10 to pass all IP packets 12 through. However, when some network congestion is detected, QoS rules 14 may be updated, causing router 10 to drop packets that have the lowest priority level, while passing higher-priority IP packets 12 to its output.
Using QoS rules helps to ensure that higher-priority packets are provided with a higher level or quality of service. For example, streaming data such as voice or video transmissions, or traffic from users who pay a premium for premium service, may have packets marked for a higher level of service than data packets for web browsing or for text messages that may be safely delayed.
FIGS. 2A-B show IP packets marked for service levels. FIG. 2A shows an older IP version 4 (IPv4) packet. IPv4 packet 20 carries data in data field 136 that is preceded by an IP header. Data field 136 may contain headers for higher-level protocols, such as a Transport-Control-Protocol (TCP) header. Version field 122 indicates the IP version that packet 20 is using. Length field 124 indicates the packet's length, while source IP address field 132 contains the IP address of the packet's source or sender, while destination IP address field 134 contains the IP address of the packet's destination or ultimate receiver. These IP addresses may be altered such as to hide the sender's true IP address behind a firewall, or to redirect or load-balance destination servers.
Checksum field 128 contains a cyclical-redundancy-check (CRC) checksum of packet 20 that is useful for detecting errors. Flags 126 contain various flags.
Type-of-service TOS field 26 is used to indicate the service level or priority. A widely used QoS protocol is Differentiated Services (DiffServ), which uses 6 bits in TOS field 26 that are known as the Differentiated Services Code Point (DSCP) bits. The DSCP bits 22 in TOS field 26 can be set to certain predefined values to indicate the packet's traffic level or priority.
For example, DSCP bits 22 in TOS field 26 can be set to indicate a lowest priority, which is the default. A router uses its best efforts to pass a packet with this default service level. A higher level of service is expedited forwarding, while assured forwarding is an even higher level of service. Packets marked for assured forwarding are much more likely to be processed through a router than default packets, which are most likely to be dropped when congestion occurs.
DSCP bits 22 in TOS field 26 can be set to other values, such as for class selector per-hop-behaviors (PHB's) that can more precisely control service at certain routers.
FIG. 2B shows a newer IP version 6 (IPv6) packet. IPv6 packet 24 carries data in data field 136, and also has version field 122, length field 124, source IP address field 132, and destination IP address field 134. Flow label field 142 and next header field 146 allow for expanded functionality.
Traffic class field 144 contains DSCP bits 22, much as TOS field 26 did for IPv4 packet 20. The traffic class or priority of this packet can be set by DSCP bits 22 in traffic class field 144. Hop limit field 148 can be used for limiting hops, which can also be used to network control traffic.
FIG. 3 shows pre-Internet congestions despite QoS traffic control on the Internet. Traffic control using QoS rules and DiffServ setting of DSCP bits 22 in traffic class or type-of-service bytes in IP packets can help to manage traffic within Internet 34. Traffic controller 33 monitors traffic and congestion and sends policy packets 35 to devices such as router 10 and edge device 38 to regulate traffic. Policy packets 35 can set QoS rules that indicate when to drop packets and what traffic classes to process.
QoS policies may be implemented in two distinct entities: a policy decision point (PDP) and a policy enforcement point (PEP). In practice, these are often run in the same physical device, such as in a traffic controller. Traffic controller 33 is a Policy Decision Point (PDP) while routers and edge devices act as Policy Enforcement Points (PEP).
While such traffic control is effective in handling congestion on Internet 34, sometimes congestion can occur in locations that are not controlled by traffic controller 33. For example, private cellular network 36 has thousands of cell phones 30 that send packets by radio-frequency (RF) transmission to base stations 32. Base station 32 reformats these packets and sends them to edge device 38, where the packets enter Internet 34. The packets are then routed through Internet 34.
Intermediate devices such as router 10 and edge device 38 can regulate packets from cell phones 30 using QoS rules, but only once these packets reach Internet 34. When too many packets are sent from cell phones 30, packets are dropped as they enter Internet 34, at edge device 38. However, these packets still pass between cell phones 30 and base station 32 before reaching edge device 38, causing congestion on the RF links. This pre-Internet congestion on private cellular network 36 is undesirable, since voice calls may be blocked by IP packets to edge device 38 that are ultimately dropped.
RF bandwidth is wasted by these dropped packets. Cell phones 30 may simply re-transmit these packets over and over again, clogging the RF links with packets that are ultimately dropped by the Internet edge device anyway.
FIG. 4 shows that a virtual-private-network (VPN) tunnel can frustrate traffic control. Encryptor 42 on cell phones 30 or on another device before the Internet edge device may encrypt data in IP packets. The encrypted IP packets are sent over the Internet and routed by router 10 and others to server 40, the destination. Server 40 decrypts the data in the IP packets using decryption software 44.
Encrypting the data in IP packets prevents others from reading the encrypted data. However, some higher-level headers may be included in the data field that is encrypted. These higher-level protocols may include information such as the name or type of application program, a higher-level port, or flow information that may be useful in classifying the IP packets into traffic classes. A traffic classifier that looks for such information to classify the IP packet by writing DSCP bits 22 using DiffServ may not be able to classify encrypted packets, and may use the lowest-priority default setting.
When the traffic classifier examines packets within the VPN tunnel, after encryptor 42, information from these higher-level protocols can be hidden, preventing proper classification. Intermediate routers such as router 10 are forced to use default priority settings, or must guess at the traffic class of these packets. Thus intermediate traffic control, such as within Internet 34 of FIG. 3, may be thwarted by packet encryption.
What is desired is a traffic control mechanism that is effective despite packet encryption and VPN tunnels. A traffic controller that can control traffic on both the Internet and on pre-Internet private networks is desirable. A traffic controller that adjusts packet traffic at the source is desirable to avoid bandwidth wasted by transmission of packets that are later dropped.